太可怕了！差点因为一条SQL被拖出去祭天……
点击上方“后端架构师”，选择“星标”公众号
重磅干货，第一时间送达！
来自：鄙人薛某 | 责编：后端君
链接：cnblogs.com/yeya/p/13200655.html
上一篇好文：图解 SQL，看这篇就对了～
# 反常的SQL语句
我眯开朦胧的双眼，才发现刚才的发声来源于我的组长庄哥，看到他在紧张的点开日志系统查看日志，我预感到有什么不妙的事情发生。
仔细一问才知道，原来就在我眯眼的期间，线上数据库服务器的 CPU 被打满，同时触发了生产数据库只读延迟的限定时间并且发出告警，而且告警的过程持续了半个小时。
这让我倒吸了一口凉气，因为我们组做的系统很多都用的是同一个数据库服务器，日用户活跃量有好几十万，如果服务器崩溃了将会使所有的系统服务都不可用。
于是我们赶紧通过 SQL 日志进行问题查找，最后排查出来是因为一张 SQL 的高量查询没有走索引导致。
日志列表显示，这条 SQL 语句的扫描行数达到了上百万，基本就是全表扫描的情况，而且半个小时的时间查询了达上万次，每条 SQL 查询的耗时都在 3000ms 以上。
我的天啊，难怪服务器会 CPU 打满，这么一条耗时的 SQL 语句查询量这么大，数据库的资源当然是直接就崩溃了。
这是当时那条 SQL 的查询情况：
# 临时处理
看了这条语句，我又倒吸一口凉气，这不就是我写的系统调用的 SQL 语句吗？完了，这回逃不掉了，真是人在睡梦里，锅从天上来。
当然，因为是我自己写的 SQL，所以我一看就知道这条语句是有问题的。
根据我的代码处理，这条 SQL 的调用还少了个重要的参数 user_fruit_id，这个参数没有传的话是不应该走这条 SQL 查询的。
在我的设计里，该参数是数据表里一个联合索引的最左侧字段，如果该字段没有传值的话，那么索引就不会生效了。
KEY `idx_userfruitid_type` (`user_fruit_id`,`task_type`,`receive_start_time`,`receive_end_time`) USING BTREE
虽然定位到了 SQL 语句，但是线上的问题刻不容缓，总不可能找出 Bug 改完再上线吧。
所以，我们只能做了一个临时处理，就是在原来的表上多加了一个联合索引，其实就是去掉了 user_fruit_id 字段，让这些高量的查询都能走新的索引。
就像下面这样：
KEY `idx_task_type_receive_start_time` (`task_type`,`receive_start_time`,`receive_end_time`,`created_time`) USING BTREE
加上索引后，SQL 的扫描行数就大幅度的降低了，重启实例后就又能正常运行了。
# 最左匹配原则
那么为什么最左侧的字段没传索引就不生效了，这是因为 MySQL 的联合索引是基于“最左匹配原则”匹配的。
我们都知道，索引的底层是 B+ 树结构，联合索引的结构也是 B+ 树，只不过键值数量不是一个，而是多个，构建一颗 B+ 树只能根据一个值来构建，因此数据库依据联合索引最左的字段来构建 B+ 树。
例如我们用两个字段（name，age）这个联合索引来分析：
图片来源于林晓斌老师的《MySQL 实战 45 讲》课程
当我们在 where 条件中查找 name 为“张三”的所有记录的时候，可以快速定位到 ID4，并且查出所有包含“张三”的记录。
而如果要查找“张三，10”这一条特定的数据，就可以用 name = "张三" and age = 10 获取。
因为联合索引的键值对是两个，所以只要前面的 name 确定的情况下就可以进一步定位到具体的 age 记录。
但是如果你的查询条件只有 age 的话，那么索引就不会生效，因为没有匹配最左边的字段，后面所有的索引字段都不会生效。
所以我之前写的 SQL 语句才会因为少了最左边的 user_fruit_id 字段而走了全表扫描的查询方式。
正常来说，假设一个联合索引设计成(a，b)这样的结构的话，那么用 a and b 作为条件，或者 a 单独作为查询条件都会走索引，这种情况下我们就不要再为 a 字段单独设计索引了。
但如果查询条件里面只有 b 的语句，是无法使用(a，b)这个联合索引的，这时候你不得不维护另外一个索引，也就是说你需要同时维护(a，b)、(b) 这两个索引。
# 找出 Bug
虽然临时做了处理，但问题并不算解决，很明显是系统出现了 Bug 才会有走这样的查询条件。
因为是我自己写的代码，所以知道是哪条 SQL 后我就马上定位到了代码里的具体方法，后来才发现是因为我对 user_fruit_id 字段的判空处理不生效所致。
因为该字段是从调用方传过来的，所以我在方法参数里对该字段做了非空限制的注解，也就是 javax 包下的 @NotNull：
public class GardenUserTaskListReq implements Serializable {
private static final long serialVersionUID = -9161295541482297498L;
@ApiModelProperty(notes = "水果id") @NotNull(message = "水果id不能为空") private Long userFruitId; /**以下省略*/ .....................}
虽然加上该注解来做非空校验，但我却没有在参数加上另一个注解 @Validated。
该注解如果没加上的话，那么调用 javax 包下的校验规则就都不生效，正确的写法是在 controller 层方法的参数前面加上注解：
除此之外，因为 user_fruit_id 这个字段是另一张表的主键，我在代码里也没有对这张表是否存在这个 id 做查询判断。
这样一来，无论调用方传什么值过来都会直接触发 SQL 查询，并且在不跑索引的情况下直接走全表扫描。
不得不说，这真是个低级错误，说真的，我对这个原因真是感到啼笑皆非，再怎么说也工作几年了，怎么还犯一些新手级别的错误呢，这脸打得真是让我相当惭愧。
# 总结
虽然是低级错误，但造成的后果也算挺严重了，这次事件也让我更加的警醒，在以后的开发工作中必须要遵守该有的原则，大概有这么几点：
①不能相信调用端。重要的参数都要先做验证，即使是非空值也需要做验证，不符合条件的就要直接返回或抛异常，不能参与业务 SQL 的查询，否则频繁的访问也会对服务造成负担。
②SQL 语句要先做性能查询。对于数据量大的表，建好索引后，所有的 SQL 查询语句要用 explain 检测性能，并且根据结果来进一步优化索引。
③代码必须要 Review。之前我没有放太大的精力在代码的 Review 上，虽说跟迭代排期的紧凑也有关系，但不管怎么说，Bug 确实是我的疏忽造成的，尤其是像空值这种细小的错误在 Java 里可以说家常便饭。
千里之堤毁于蚁穴，有时一个小 Bug 很容易就引发整个系统的崩盘，这一次的问题也让我更加深刻的认识到了 Review 代码的重要性，不管业务开发的工作量有多麻烦，这一步操作绝对不能忽视。
码字不易，如果你觉得读完以后有收获，不妨点个在看让更多的人看到吧~
来自：鄙人薛某 | 责编：后端君
链接：cnblogs.com/yeya/p/13200655.html
上一篇好文：图解 SQL，看这篇就对了～
# 反常的SQL语句
仔细一问才知道，原来就在我眯眼的期间，线上数据库服务器的 CPU 被打满，同时触发了生产数据库只读延迟的限定时间并且发出告警，而且告警的过程持续了半个小时。
这让我倒吸了一口凉气，因为我们组做的系统很多都用的是同一个数据库服务器，日用户活跃量有好几十万，如果服务器崩溃了将会使所有的系统服务都不可用。
于是我们赶紧通过 SQL 日志进行问题查找，最后排查出来是因为一张 SQL 的高量查询没有走索引导致。
日志列表显示，这条 SQL 语句的扫描行数达到了上百万，基本就是全表扫描的情况，而且半个小时的时间查询了达上万次，每条 SQL 查询的耗时都在 3000ms 以上。
我的天啊，难怪服务器会 CPU 打满，这么一条耗时的 SQL 语句查询量这么大，数据库的资源当然是直接就崩溃了。
# 临时处理
当然，因为是我自己写的 SQL，所以我一看就知道这条语句是有问题的。
根据我的代码处理，这条 SQL 的调用还少了个重要的参数 user_fruit_id，这个参数没有传的话是不应该走这条 SQL 查询的。
KEY `idx_userfruitid_type` (`user_fruit_id`,`task_type`,`receive_start_time`,`receive_end_time`) USING BTREE虽然定位到了 SQL 语句，但是线上的问题刻不容缓，总不可能找出 Bug 改完再上线吧。
所以，我们只能做了一个临时处理，就是在原来的表上多加了一个联合索引，其实就是去掉了 user_fruit_id 字段，让这些高量的查询都能走新的索引。
就像下面这样：
KEY `idx_task_type_receive_start_time` (`task_type`,`receive_start_time`,`receive_end_time`,`created_time`) USING BTREE加上索引后，SQL 的扫描行数就大幅度的降低了，重启实例后就又能正常运行了。
# 最左匹配原则
那么为什么最左侧的字段没传索引就不生效了，这是因为 MySQL 的联合索引是基于“最左匹配原则”匹配的。
我们都知道，索引的底层是 B+ 树结构，联合索引的结构也是 B+ 树，只不过键值数量不是一个，而是多个，构建一颗 B+ 树只能根据一个值来构建，因此数据库依据联合索引最左的字段来构建 B+ 树。
图片来源于林晓斌老师的《MySQL 实战 45 讲》课程
当我们在 where 条件中查找 name 为“张三”的所有记录的时候，可以快速定位到 ID4，并且查出所有包含“张三”的记录。
而如果要查找“张三，10”这一条特定的数据，就可以用 name = "张三" and age = 10 获取。
因为联合索引的键值对是两个，所以只要前面的 name 确定的情况下就可以进一步定位到具体的 age 记录。
但是如果你的查询条件只有 age 的话，那么索引就不会生效，因为没有匹配最左边的字段，后面所有的索引字段都不会生效。
所以我之前写的 SQL 语句才会因为少了最左边的 user_fruit_id 字段而走了全表扫描的查询方式。
正常来说，假设一个联合索引设计成(a，b)这样的结构的话，那么用 a and b 作为条件，或者 a 单独作为查询条件都会走索引，这种情况下我们就不要再为 a 字段单独设计索引了。
但如果查询条件里面只有 b 的语句，是无法使用(a，b)这个联合索引的，这时候你不得不维护另外一个索引，也就是说你需要同时维护(a，b)、(b) 这两个索引。
# 找出 Bug
虽然临时做了处理，但问题并不算解决，很明显是系统出现了 Bug 才会有走这样的查询条件。
因为是我自己写的代码，所以知道是哪条 SQL 后我就马上定位到了代码里的具体方法，后来才发现是因为我对 user_fruit_id 字段的判空处理不生效所致。
public class GardenUserTaskListReq implements Serializable {
private static final long serialVersionUID = -9161295541482297498L;
@ApiModelProperty(notes = "水果id") @NotNull(message = "水果id不能为空") private Long userFruitId; /**以下省略*/ .....................}虽然加上该注解来做非空校验，但我却没有在参数加上另一个注解 @Validated。
除此之外，因为 user_fruit_id 这个字段是另一张表的主键，我在代码里也没有对这张表是否存在这个 id 做查询判断。
不得不说，这真是个低级错误，说真的，我对这个原因真是感到啼笑皆非，再怎么说也工作几年了，怎么还犯一些新手级别的错误呢，这脸打得真是让我相当惭愧。
# 总结
虽然是低级错误，但造成的后果也算挺严重了，这次事件也让我更加的警醒，在以后的开发工作中必须要遵守该有的原则，大概有这么几点：
①不能相信调用端。重要的参数都要先做验证，即使是非空值也需要做验证，不符合条件的就要直接返回或抛异常，不能参与业务 SQL 的查询，否则频繁的访问也会对服务造成负担。
②SQL 语句要先做性能查询。对于数据量大的表，建好索引后，所有的 SQL 查询语句要用 explain 检测性能，并且根据结果来进一步优化索引。
③代码必须要 Review。之前我没有放太大的精力在代码的 Review 上，虽说跟迭代排期的紧凑也有关系，但不管怎么说，Bug 确实是我的疏忽造成的，尤其是像空值这种细小的错误在 Java 里可以说家常便饭。
千里之堤毁于蚁穴，有时一个小 Bug 很容易就引发整个系统的崩盘，这一次的问题也让我更加深刻的认识到了 Review 代码的重要性，不管业务开发的工作量有多麻烦，这一步操作绝对不能忽视。
码字不易，如果你觉得读完以后有收获，不妨点个在看让更多的人看到吧~
PS：如果觉得我的分享不错，欢迎大家随手点赞、转发、在看。 版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
END
历史好文：
扫码关注我们
历史好文：
扫码关注我们